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The  challenge 


WE  START 
SHIPPING  IN 
TWO  WEEKS. 


THAT'S  NOT  ENOUGH 
TIKE  TO  FIX  THE 
KNOWN  BUGS. 


OR  PERHAPS  THE 
INTERFACE  IS  A 
BIT  UNCLEAR. 


OR  PERHAPS  IT  CAN 
ONLY  BE  OPERATED 
BY  A  ROBOT  FROK  THE 
FUTURE  WHO  JACKS 
INTO  IT  AND  SENDS 
COKKANDS  IN  ZEROS 
AND  ONES. 


WHEN 
YOU  SAY 
"BUGS," 
THAT'S 
SORT  OF 
A  GRAY 
AREA. 

V 


UK. .  .1 
DON'T 
THINK 
IT  IS. 


V 


I 


FOR  EXAKPLE,  A  USER 
KIGHT  NEED  SEVERAL 
STEPS  TO  DO  SOKE- 
THING  THAT  SHOULD 
ONLY  TAKE  ONE. 


I  CAN'T  TELL  IF 
YOU'RE  AGREEING 
WITH  KE  OR 
KOCKING  KE. 


THAT'S 
SORT  OF  A 
GRAY  AREA. 


DILBERT:  @Scott  Adams/Dist.  By  United  Feature  Syndicate,  Inc 


Tradeoffs  and  their  dependencies  must  be  supported  by  both 
Agile  software  development  and  architecture  practices 
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The  challenge 
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neglected  cost  of 
delay  to  market 


underestimated 
re-architecting  costs 


First ,  more  infrastructure 


Then ,  more  capabilities 


Brown,  N.,  Nord,  R.,  and  Ozkaya,  I.  “Enabling  Agility  Through 
Architecture.”  Crosstalk 23,  6  (Nov./Dec.  2010):  12-17. 
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Increased  visibility  into  delivery 


Focus  on  Priority 
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Agenda 

Symptoms  of  failure 

Concepts  of  scale  and  root-cause  analysis 
Tactics  that  can  help 

•  Align  feature  and  system  decomposition. 

•  Create  an  architectural  runway. 

•  Use  matrix  teams  and  architecture. 
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Symptoms  of  failure 


■  Teams  (e.g.,  Scrum  teams,  product  development 
teams,  component  teams,  feature  teams)  spend 
almost  all  of  their  time  fixing  defects,  and  new 
capability  development  is  continuously  slipping. 


■  Integration  of  products  built  by  different  teams  reveals  that 
incompatibility  defects  cause  many  failure  conditions  and 
lead  to  significant  out-of-cycle  rework  in  addition  to  end-to- 
end  fault-tolerance  failure. 


■  Progress  toward  meeting  milestones  is  unsatisfactory. 
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Scope 


Scope  drivers 

Fundamental  project 
management  concerns  are 
essential  to  keep  in  mind: 

•  If  the  schedule  needs  to  be  shorter, 
you  may  see  an  increase  in  cost  and 
a  decrease  in  scope. 


Traditional  approach  : 
Fixed  scope  driving  cost 
and  schedule 


•  If  cost  becomes  an  issue,  you  may 
see  a  decrease  in  scope  or  an 
increase  in  schedule. 

•  If  scope  is  increased,  you  may  see  an 
increase  in  both  cost  and  schedule. 


Scope 


Agile  project  management  approach: 


Fixed  cost  and  schedule 
driving  scope 
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A  closer  look  at  scale:  Scope 


Is  the  project  in  a  new  domain  or 
technology? 


Does  the  project  have  new 
requirements  such  as  standards 
compliance,  system  testing,  and 
integration  lab  environments,  or 
does  it  simply  have  more  features, 
elements,  and  relationships? 


Is  there  a  need  to  align  systems 
engineering  and  software 
development  activities? 
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A  closer  look  at  scale:  Team 


•  Are  there  multiple  teams  that  need 
to  interact,  both  internal  and 
external  to  the  organization? 


•  What  are  the  dependencies 
between  the  work  products  of 
system  and  software  engineers? 


•  Have  you  considered  the  end-to- 
end  success  of  features  that  may 
require  resources  from  multiple 
teams? 
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A  closer  look  at  scale: 


Software  Engineering  Institute 


Carnegie  Mellon 


•  Does  the  work  require 
different  schedule  constraints 
for  releases? 


•  How  long  is  the  work  product 
expected  to  be  in  service? 


•  How  important  are 
sustainability  and  evolution? 
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Polling  question 


Are  you  currently  doing  development  in  a  large-scale  context  that 
can  be  captured  by  extended  scope,  team  size,  or  timelines  of 
scale? 


1.  Large  team  size 

2.  Larger  than  normal  scope 

3.  Longer  development  roadmap 

4.  Product  expected  to  be  in  service  for  a  long  time 

5.  At  least  two  of  the  above 
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Root-cause  analysis 


Business 

Response  to 
Change 

Culture 

Team  Support 

Quality 

Attributes 

Customer 

Collaboration 

Architecture 

Productivity 

Measures 

Investigate  both  technical  and  nontechnical  areas,  looking  at  both 
Agile  software  development  and  software  architecture  fundamentals. 
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Root-cause  analysis 


Response  to  change 

•  Dynamic  environment  and  changing 
requirements  are  understood. 

•  Necessary  technology  and  processes  are 
identified  to  respond  to  change. 

•  Impact  of  uncertainty  on  the  project  is 
acknowledged. 

•  Waste  is  identified  and  tradeoffs  managed 
(e.g.,  technical  debt  and  defects). 


Business 

Response  to 
Change 

Culture 

Team  Support 

Quality 

Attributes 

Customer 

Collaboration 

Architecture 

Productivity 

Measures 
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Root-cause  analysis 


Culture 

•  People  are  made  available  (internal  and 
external),  including  an  appropriate  number 
of  people  who  have  the  right  skills  and 
knowledge  and  clear  responsibilities. 

•  Team  members  are  motivated  and 
empowered  by  many  degrees  of  freedom. 

•  Clear  communication  among  teams  and 
team  members  is  established. 

•  There  is  high-level  management  support. 


Business 

Response  to 
Change 

Culture 

Team  Support 

Quality 

Attributes 

Customer 

Collaboration 

Architecture 

Productivity 

Measures 
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Root-cause  analysis 


Quality  attributes 

•  The  importance  of  quality  attribute 
requirements  is  understood. 

•  Quality  attribute  requirements  are  defined 
and  tied  to  business  goals. 

•  Means  for  analysis  of  necessary  quality 
attributes  are  in  place  and  used  to  predict 
system  properties. 

•  Measurement  environment  is  in  place  to 
monitor  the  implemented  system  quality 
and  “done”  criteria. 


Business 

Response  to 
Change 

Culture 

Team  Support 

Quality 

Attributes 

Customer 

Collaboration 

Architecture 

Productivity 

Measures 
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Root-cause  analysis 


Architecture 

•  Evidence  is  provided  that  the  architecture 
satisfies  quality  attribute  requirements. 

•  Appropriate  functional  requirements  are 
assigned  to  architecture  elements. 

•  Architectural  issues  (e.g.,  technical  debt) 
are  tracked  and  managed. 

•  Timeline  of  critical  architectural  decisions 
is  clear  and  scheduled. 


Business 

Response  to 
Change 

Culture 

Team  Support 

Quality 

Attributes 

Customer 

Collaboration 

Architecture 

Productivity 

Measures 
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Tactics  to  consider 


Align  feature  and  system  decomposition. 
Create  an  architectural  runway. 

Use  matrix  teams  and  architecture. 
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Align  feature  and  system  decomposition 


Dependencies  between 
stories  &  supporting 
architectural  elements 


Understanding  the  dependencies  between 
stories  and  architectural  elements  enables 
staged  implementation  of  technical 
infrastructure  in  support  of  achieving 
stakeholder  value. 


Dependencies  among 
architectural  elements 


Low-dependency  architectures  are  a  critical 
enabler  for  scaling  up  Agile  development.1 


Dependencies  among 
stories 


High-value  stories  may  require  the 
implementation  of  lower  value  stories  as 
precursors.2 


1 .  Poppendieck,  M.,  and  Poppendieck,  T.  Leading  Lean  Software  Development.  Addison-Wesley 
Professional,  2009. 

2.  Denne,  M.,  and  Cleland-Huang,  J.  Software  by  Numbers.  Prentice  Hall,  2003. 
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Align  feature  and  system  decomposition 


Tension  between  high-priority  features  (vertical  decomposition) 
versus  common  reusable  services  (horizontal  decomposition) 


Infrastructure-driven 

approach 


Applications 


Drivers 


Horizontal  decomposition 
(e.g.,  layers) 


Feature-driven 

approach 


Vertical  decomposition 
(e.g.,  subsystems,  features) 


Hybrid  approach 
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Align  feature  and  system  decomposition 

Two  examples 


Presentation  Layer 


Future 

^Framework 

O 

o 

Common  Services 

API 


Domain  Layer 

Framework 


Common  Services 

API 

Data  Access  Layer 


O 

Framework 

Feature 

o  o 

Common  Services 

Layered  architecture  with  frameworks 


Presentation  Layer 
Feature 


Plug-in  Interfaces 

Common  Services 


API 


Domain  Layer 
Feature 


Plug-in  Interfaces 

Common  Services 


API 


Data  Access  Layer 
Feature 


Plug-in  Interfaces 

Common  Services 
Layered  architecture  with  plug-ins 


Decouple  teams  and  architecture  to  ensure  parallel 
progress  as  the  number  of  teams  increases. 


C^)  Un implemented  feature 


I  Feature 
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Create  an  architectural  runway 

The  architectural  runway  provides  the  degree  of 
architectural  stability  to  support  the  next  n  iterations 
of  development. 

In  a  Scrum  project  environment,  the  architectural 
runway  may  be  established  during  Sprint  0. 

•  Sprint  0  might  have  a  longer  duration  than  the  rest  of 
the  sprints. 
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Create  an  architectural  runway 


Agile  Project  Kickoff 


■  * 

Time 


|1  1 2  1 3  |4  1 5 


Feature  Team  1 


*• 


Feature  Team  2 


Initial  Project 
Team 


System  Team 

(Architecture,  Prototyping) 


infrastructure 
Component  Team  1 


©  2008  Leffingwell,  LLC. 

The  bigger  the  system,  the  longer  the  runway. 
Leffingwell,  Martens,  Zamora 

Leffingwell,  D.  Scaling  Software  Agility.  Addison-Wesley,  2007. 

http://scalingsoftwareagility.wordpress.com/2008/09/09/enterprise-agility-the-big-picture-10-the-system-team 
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Use  matrix  teams  and  architecture 


Establishing  the  infrastructure 
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Use  matrix  teams  and  architecture 


Feature  development  in  parallel 


#  Team  member  with  feature  responsibility 
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Use  matrix  teams  and  architecture 


Different  teams  are 
assigned  to  different 
features,  and  some 


Scrum  of 
Scrums 
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Use  matrix  teams  and  architecture 
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Root-cause  analysis:  Typical  problem  1 


Symptom 

•  Scrum  teams  spend  almost  all  of  their  time  fixing  defects,  and  new 
feature  development  is  continuously  slipping. 

Root-cause 

Inability  to  manage  scope  and  time  at  scale 

•  Initial  focus  was  “general”  rather  than  “product  specific.” 

-Time  pressure  to  deliver  became  the  top  priority. 

-The  team  delivered  an  immature  product. 

-A  plethora  of  variation  parameters  interact  detrimentally. 

•  There  are  three  different  cycles: 

-Customer  release  (annually,  many  variants);  IV&V  Testing 
(quarterly,  4  variants),  and  Developmental  (monthly,  1  variant) 
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Solution 


Stabilize  the  architecture. 

•  Build  an  architecture  for  current  products. 

-Rules,  guidelines 

-Over  a  few  time  boxes 

•  Reduce  the  number  of  “variant  parameterizations.” 

•  Make  everyone  play  from  the  same  sheet  music. 

•  Postpone  adding  new  features. 

Replan  the  release  cycles/time  boxes. 

Revisit  the  testing  strategy/team  assignments  against 
variants. 
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Root-cause  analysis:  Typical  problem  2 


Symptom 

•  Integration  of  products  built  by  different  Scrum  teams  reveals  that 
incompatibility  defects  cause  many  failure  conditions  and  lead  to 
significant  out-of-cycle  rework. 


Root  -cause 

Inability  to  manage  teams  at  scale 

•  Cross-team  coordination  is  poor,  even  though  there  are  many 
coordination  points  and  much  time  spent. 

•  Different  teams  have  different  interpretations  of  interfaces. 

•  The  product  owner  on  each  Scrum  team  does  not  see  the  big  picture. 

•  A  mismatch  exists  between  the  architecture  and  Scrum  development. 
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Solution 


Stabilize  to  remove  failures. 

•  Postpone  adding  new  features. 

Identify  and  collapse  common  services  across  teams. 

Use  an  architectural  runway. 

•  A  system  that  has  an  architectural  runway  contains 
existing  or  planned  infrastructure  sufficient  to  allow 
incorporation  of  current  and  near-term  anticipated 
requirements  without  excessive  refactoring. 

•An  architectural  runway  is  represented  by  infrastructure 
initiatives  that  have  the  same  level  of  importance  as  the 
larger  scale  requirements  epics  that  drive  the  company’s 
vision  forward. 
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Root-cause  analysis:  Typical  problem  3 

Symptom 

•  Progress  toward  meeting  milestones  is  unsatisfactory. 


Root-cause 

Inability  to  manage  teams  and  scope  at  scale 

•  Mapping  of  features  to  software  components  per  Scrum 
cycle  is  disorganized. 

•  Some  new  features  are  unused  in  each  cycle,  causing 
wasted  effort. 

•  Developer  assignment  to  teams  is  inflexible. 
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Solution 


Build  more  architectural  views  to  align  features  between 
teams. 

Reorganize  teams  to  better  fit  iteration  and  release 
workloads. 

Create  matrix  teams  to  clean  up  unused  features. 
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Final  thoughts 


No  one  tactic  alone  can  take  any  project  to  success. 

Systematic  root-cause  analysis  is  essential  for  understanding 
risks  arising  in  large-scale  software  development. 

There  are  different  aspects  of  scale  that  may  need  to  be 
managed  with  different  approaches,  such  as  scope,  team, 
and  time. 

Embracing  the  principles  of  both  Agile  software  development 
and  software  architecture  provide  improved  visibility  of  project 
status  and  better  tactics  for  risk  management. 

•  Align  feature  and  system  decomposition. 

•  Create  an  architectural  runway. 

•  Use  matrix  teams  and  architecture. 
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